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REMARKS 

Reconsideration and allowance of the subject application are respectfully requested in 
light of the amended claims and the arguments set forth below. 

Claims 1-35 stand rejected under 35 U.S.C. 103 as being unpatentable in view of the 
Winzip helpfile document. This rejection is respectfully traversed. 

There are several known techniques for storing a large number of documents in a 
database. A single document in the database may contain references to other documents, 
graphics files, and/or sound files of the same database or even to a separate database. An 
example of such a document is an HTML document widely used in the Internet/World Wide 
Web (WWW) environment. Typically, a database of HTML documents is stored on a web 
server connected to the World Wide Web. A user can browse documents stored in the database 
at the web server using a web browser. Typically, the web server receives a uniform resource 
locator (URL) request from the web browser, decodes URL, handles the document files, and 
sends the requested files to the web browser. It is also possible to browse documents locally in a 
local file system in a stand-alone data processing device that is not connected to the World Wide 
Web. In this case, the document address corresponding to a local file path is given to the local 
file system which then retrieves the file for the browser. 

These conventional arrangements are problematic in a situation where a document 
database has been configured so that a set of multiple documents is stored as a single file . 
Typically, the browser can only access separate documents located at a given URL address. But 
in a single file database structure, those documents stored in the single file can not be accessed in 
this traditional fashion. 
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Nevertheless, there is a significant advantage to structuring a database that includes 
thousands of individual documents by storing them as a single file. A single file can be managed 
much more easily than thousands of separate files, some of which may be of different file types. 
Moreover, the single file is more readily assigned a product identity and a version identifier, 
facilitating guarantee of the quality of the information contained in the database through proper 
version handling. 

Each of the multiple documents in a single file database typically contains links or 
references to other documents in that database. This creates a problem if it is desired to make the 
database transferable to different locations. In other words, the document links or references 
must be defined and handled so that a location- independent database can be achieved. 
Moreover, it would advantageous if the single file database could be defined so that the same 
database management could be used in a network context (the database could be copied to any 
network server), and a local file system in a stand-alone data processor (the database could be 
copied to any file path in the file system). 

The present invention solves these problems and achieves these desirable objectives by 
storing the multiple documents in a single file database using a specialized protocol. A non- 
limiting example of this single file database protocol is set forth in the detailed description 
starting on page 1 1 and is referred to as 'edw'. But the browser does not understand a 
specialized, single file database syntax. Accordingly, the references in the documents (e.g., 
URL's) must be transformed before a document in the database can be provided to the browser 
for display. This is true for a network server application and for a stand-alone data processor 
application. 
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The Winzip helpfile document lacks multiple features recited in the independent claims. 
It allows multiple files to be compressed and stored as a single archive file called a zip file. 
Those files can also be extracted and decompressed using an unzip operation. The step by step 
example the Examiner relies on in pages 6-8 describes creating two simple text document files 
one.txt and two.txt, saving them to a directory c:\foo, and creating a zip file c:\foo/test.zip to 
archive those files. Winzip allows viewing the files simply by double clicking on the filename or 
by performing an extract operation. 

There is no teaching of either one of the two document files one.txt and two.txt stored in 
the zip file "containing links" or references to the other file. Where in the Winzip helpfile 
document is one of one.txt and two.txt files described as having "links" to the other text file? 
The Examiner states that "HTML documents include hyperlinks that point to other documents." 
This is speculation by the Examiner. There is no teaching in the Winzip helpfile document that 
either of the two document files one.txt and two.txt is an HTML document. The terms link and 
reference have been defined in the claims in response to the Examiner's statements in the 
advisory action regarding his broad reading of the term "link." A link or a reference identifies 
one other document in the database and is useable to retrieve the other document from the 
database. 

To contend that these files "could be" HTML documents or that such links "could be" 
inserted into the two documents is impermissible hindsight. Many different executable file 
formats are described in the Winzip helpfile document, but the Examiner has not identified 
where HTML documents are described. The standard for obviousness is not the feasibility of 
doing something. There must be some express motivation in the prior art that suggests the 
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desirability of doing it. See Winner Int'l Royalty Corp. v. Wang, 202 F.3d 1340, 1349 (Fed. Cir. 
2000). 

Where does the Winzip helpfile document describe scanning either document for links? 
The Examiner again improperly assumes that the two document files are HTML documents 1 and 
seems to liken the claimed scanning for document links to compressing a file. The Examiner is 
requested to explain how compressing a file, where the amount of data in the file is reduced 
regardless of whether the data is a link or not, is the same as scanning a file for links, particularly 
HTML links since the Examiner is contending that the WinZip files are HTML documents. 

The Examiner's contentions regarding "transforming the links into a format which is 
recognizable by the document browser" are untenable. The Examiner apparently abandons the 
earlier contention that NOTEPAD is the claimed browser. But what is the Examiner now 
reading the claimed browser on? 2 If one accepts the Examiner's contention that a ZIP file is a 
single file database, then the "electronic document browser" requesting a compressed file in the 
ZIP file is the WinZip main window. But there is nothing in the Winzip helpfile document that 
describes the WinZip main window as understanding HTML or links within an HTML document 



1 The Examiner quotes from the Microsoft Computer Dictionary. That dictionary defines a document as "document; 
Any self-contained piece of work created within an application program and, if saved on disk, given a unique 
filename by which it can be retrieved. Documents are generally thought of as word-processed materials only. To a 
computer, however, data is nothing more than a collection of characters, so a spreadsheet or a graphic is as much a 
document as is a letter or report. In the Macintosh environment in particular, a document is any user-created work 
named and saved as a separate file." 

2 Again from the Microsoft Computer Dictionary: "Web browser: Software that lets a user view HTML documents 
and access files and software related to those documents. Originally developed to allow users to view or browse 
documents on the World Wide Web, Web browsers can blur the distinction between local and remote resources for 
the user by also providing access to documents on a network, an intranet, or the local hard drive. Web browser 
software is built on the concept of hyperlinks, which allow users to point and click with a mouse in order to jump 
from document to document in whatever order they desire. Most Web browsers are also capable of downloading and 
transferring files, providing access to newsgroups, displaying graphics embedded in the document, playing audio 
and video files associated with the document, and executing small programs, such as Java applets or ActiveX 
controls included by programmers in the documents. Helper applications or plug-ins are required by some Web 
browsers to accomplish one or more of these tasks. Also called: browser." 
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as the Examiner's reading of the claim in the final rejection and response to arguments contends. 

Indeed, as the Examiner appreciates, double-clicking on a file in the WinZip main 
window causes another application outside of the WinZip main window browser to open the file, 
like a web browser. But the claims do not recite two browsers — rather the browser that 
requested the document from the single database is the same browser for which the link format 
must be transformed. The Examiner's rejection improperly requires two different browsers: the 
WinZip main window browser and an HTML browser. Moreover, there is no teaching of any 
HTML browser in the Winzip helpfile document. 

A broadest reasonable claim interpretation must be consistent to be reasonable. 
Requiring two different browsers to perform claim functions performed by one and the same 
browser in the claim is inconsistent. Speculations about HTML documents and HTML browsers 
that are not supported by any evidence in the prior art reference are likewise unreasonable. 
"Broad" claim interpretation does not remove the Examiner's burden to provide evidence of 
claim features in the applied prior art reference. The claims now recite that the single file 
database format is modified or transformed into a browser-friendly format that includes a 
location of the database server and an identification of the database and the database server. 

In addition, the Federal Circuit requires consideration of the problem confronted by the 
inventor in determining whether it would have been obvious to combine references in order to 
solve that problem. Northern Telecom, Inc. v. Datapoint Corp., 908 F.2d 931, 935 (Fed. Cir. 
1990). Indeed, the Examiner must show reasons why one of ordinary skill in the art, confronted 
with the same problem as the inventor and with no knowledge of the claimed invention, would 
select the elements from the cited prior art references for combination in the manner claimed. 
See In re Rouffet, 149 F.3d 1350, 1357 (Fed. Cir. 1998). 
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There is certainly no recognition in the Winzip helpfile document of the problems of 
using such a single file database when documents are retrieved by web browsers. Absent that 
recognition, it is clear that the Examiner's attempted combination lacks the requisite motivation. 
This is yet another deficiency in the final rejection. The Rouffet Court warned against "rejecting 
patents solely by finding prior art corollaries for the claimed elements" because that would 
"permit an Examiner to use the claimed invention itself as a blueprint for piecing together 
elements in the prior art." In re Rouffet, 149 F.3d at 1357. That approach was found by the 
Federal Circuit to be "an illogical and inappropriate process by which to determine 
patentability." Sensonics v. Aerosonic Corp., 85 F.3d 1566, 1570 (Fed. Cir. 1996). 

The application is now in condition for allowance. An early notice to that effect is 
earnestly solicited. 



JRL:sd 

901 North Glebe Road, 1 1th Floor 
Arlington, VA 22203-1808 
Telephone: (703) 816-4000 
Facsimile: (703) 816-4100 



Respectfully submitted, 



NIXON & VANDERHYE P.C. 




Reg. No. 33,149 



- 15- 



